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Remarks 

The amended claims 

Claims 1 and 25 have been amended to more clearly define the "field whose value is a 
representation of the set". As amended, the "representation specifies individual members of the 
5 set". Examples of set representations which have this property are sho>vn at 305 and 307 in 
Applicants* FIG 3 and discussed at page 6, line 23-page 8, line 14. The claims are thus fully 
supported by the Specification as filed. Claims 3 and 27 have been amended to conform to the 
amendments in claims 1 and 25. 

10 Patentability of the claims over Bakalash 

A claim may be rejected xinder 35 U.S.C. 102 only if the reference used to make the rejection 
discloses every limitation of the claim under rejection. See MPEP 2131. The independent 
claims are claims 1 and 23; a feature of both amended claims which distinguishes them from 
Bakalash is the claims' "aggregated entr>^" which includes "a field whose value is a 

15 representation of a set, the representation specifying individual members of the set" and in 
which the individual members of the set are "deriv[ed] from values contained in entries 
belonging to the plurality thereof. 

Bakalash's failure to disclose an "aggregated entry" with a "a field whose value is a 
20 representation of a set, the representation specifying individual members of the set" 

In her Advisorj' Action, Examiner indicates that Applicants' "aggregated entiy" is disclosed in 
Bakalash at paragraphs [0055]-[0O57] and {0073]-[0074]. 

25 The disclosure of Bakalash 

Bakalash's paragraphs 0024-0026 and FIGs. IB, 2, and 3 give an overview of Bakalash's 
disclosure. As described in paragraph 0025, FIG. IB shows a multi-dimensional database 
(MDDB) into which base data is loaded by a base data loader. In the MDDB, the aggregation 
program from an Access, Aggregation, and Retrieval module builds up layers of aggregated data 

30 on top of the base data The aggregated data is organized according to a number of dimensions. 

FIG. 2B shows a three-dimensional MDDB in which each record in the MDDB has two fields: 
a dollar field indicating the purchase price and a units field indicating the number of units of a 
product purchased for the price. The dimensions in the MDDB are geography, products, and 
35 periods of time. The MDDB will return a record specifying dollars and units for each possible 
combination of geography, products, and time. For example, if the product is a widget and 25 
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widgets were sold on July 20, 2005 in Cincinnati for $4.00 apiece at a total price of $100.00, the 
MDDB will return a record having the field values $100, 25 when {widget, July 20, 2000, 
Cincinnati} is specified to the MDDB. If 100 widgets were sold in all of Ohio the d^^ of July 
20, 2005, the MDDB will return a record having the field values $400, 100 when {widget, July 
5 20, 2005, Ohio} is specified. If 800 widgets were sold in all of Ohio the week of July 20, 2000, 
the MDDB wM return the field values $3200, 800) when {widget, week containing July 20, 
2005, Ohio} is specified. As is apparent from the foregoing, the base data is aggregated along 
the various geography, time, and product dimensions of the MDDB. To speed up operation of 
the MDDB, after the base data has been loaded into the MDDB, the aggregation module pre- 
10 aggregates the data None of the aggregation entries, however, contains "a field whose value is 
a representation of a set, the representation specifying individual members of the set", as 
required by amended claim 1. 

FlGs. 9(A-C2) and lOA and the description of these figures at paragraphs 0140-0144 disclose 
15 the technique of segmented aggregation which is used in Bakalash's system to aggregate data 
FIG. lOA discloses how sparse aggregated data is indexed along dimension lines. Again, there 
is simply no disclosure here of "a field whose value is a representation of a set, the 
representation specifying individual members of the set". Moreover, a Lexis search of the use 
of the term "set" in the reference discloses many uses of the term, but no use in the mathematical 
20 sense of the term "set". It is of course that sense in which the term is used in Applicants' 
Specification and in claim 1. 

The locations cited bv Examiner 

[0055]-[0057] are part of a description of relational OLAP (ROLAP) and multidimensional 

25 OLAP (MOLAP) systems from the Brief description of (he state of the art portion of Bakalash's 

Specification. The only part of the ROLAP description that appears to be relevant is a statement 

in [0055] that "if required by the data model, database routines are run to pre-aggregate the data 

within the RDBMS". [0056] and [0057] contain the MOLAP description. The only part of that 

description that appears to be relevant is the following from [0056] : 

30 As showai in FIG. 15, such MOLAP systems have an aggregation engine 

which is responsible for all data storage, access, and retrieval processes, 
including data aggregation (i.e. pre-aggregation) in the MDDB, 

[0073]- [0074] are part of a general discussion of aggregation in the Brief description of the 
35 state of the art: 
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[0073] One of the most fundamental principles of the multidimensional database 
is the idea of aggregation. The most common aggregation is called a roll-up 
aggregation. This type is relatively easy to compute: e.g. taking daily sales totals 
and rolling them up into a monthly sales table. The more difficult are analytical 
5 calculations, the aggregation of Boolean and comparative operators. However 

these are also considered as a subset of aggregation. 

[0074] In a star schema, the results of aggregation are summary tables. Typically, 
summaiy tables are generated by database administrators who attempt to 

10 anticipate the data aggregations that the users will request, and then pre-build 

such tables. In such systems, when processing a user-generated quer>^ that 
involves aggregation operations, the pre-built aggregated data that matches the 
query is retrieved from the summar>^ tables (if such data exists). FIGS. 18A and 
18B illustrate a multi-dimensional relational database using a star schema and 

15 summary tables. In this example, the summaiy tables are generated over the 

"time" dimension storing aggregated data for "month", "quarter*' and "year" time 
periods as shown in FIG. 188. Summary tables are in essence additional fact 
tables, of higher levels. They are attached to the basic fact table creating a 
snowflake extension of the star schema There are hierarchies among summarj' 

20 tables because users at different levels of management require different levels of 

summarization. Choosing the level of aggregation is accomplished via the "drill- 
down" feature. 

None of the cited locations discloses anything about aggregation beyond what is discussed in 

25 pages 1-4 of Applicants' Descnption of related art. There is no disclosure whatever of the 
claimed "aggregated entry" which includes "a field whose value is a representation of a set, the 
representation specifying individual members of the set" and in which the "the individual 
members specified in the representation of the set [are derived from] from values contained in 
entries belonging to the plurality thereof. The lack of any such feature in Bakalash is 

30 confirmed by the comment in [0074] that "there are hierarchies among summaiy tables because 
users at different levels of management require different levels of summarization" and also the 
comment at [0077] that "summary tables do not provide a mechanism that allows efficient drill 
down to view the raw data that makes up the summary^ table-typically a table scan of one or 
more large tables is required". Applicants* claimed "aggregated entry" which includes "a field 

35 whose value is a representation of a set that is capable of having a pluralit)' of members" 
preserves the raw data in the summary tables and thus reduces the depth of the hierarchy. The 
claimed "aggregated entr>'" also makes it easier to drill down to view the raw data. In the 
system management context in which a preferred embodiment of Applicants' invention is 
employed, the claimed "aggregated entry" further makes it possible to delete the table entries 

40 that originally contained the raw data without losing the raw data. 
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It should further be pointed out here that because Bakalash does not disclose an aggregated 
entry of the kind required by the claim, Bakalash also cannot disclose the step of " deriving the 
individual members specified in the representation of the set from values contained in entries 
belonging to the plurality thereof 

5 

Patentability^ of claims 1 and 25 over Bakalash 

Because Bakalash does not disclose either Applicants* limitation of "a field whose value is a 
representation of a set, the representation specifying individual members of the set" or the 
limitation in the last method step that the "individual members specified in the representation of 
10 the set [are derived] from values contained in entries belonging to the plurality thereof," claims 
1 and claim 25 as amended are not anticipated by Bakalash. Further because the remaining 
claims are all dependent either from patentable claim 1 or patentable claim 25, they are also 
patentable. 

15 Patentability of the dependent claims in their ovvn rights 

Additionally, the dependent claims set forth limitations which arc not disclosed in Bakalash, and 
are consequently pataitable in their own rights over the references. Beginning with claims 2 
and 26, the added limitation is that "the plurality of entries represented by the aggregated entry 
[are deleted]" from their table of origin. In her rejection. Examiner refers Applicants to 

20 paragraphs [0216] and [0258]. [0216] refers to items of a "work list" that are deleted after they 
are processed [0214] makes it clear that the items on the work list are copies of items on an 
ordered list of items; the deletion of an item on the work list thus has no effect on the ordered 
list of items or on the actual sources of the ordered list. [0258] discusses FIG, 22, which 
discloses an embodiment in which an RDBMS is a component of a data warehouse system. 

25 There is absolutely nothing in [0258] concerning deletion of data from tables. Thus, neither 
[0216] nor [0258] discloses the added limitation and claims 2 and 26 are patentable in their own 
rights over the references. 

Claims 3-6 and 27-30 set forth further limitations concerning claim 1 and claim 26*s limitation 
30 of the "representation specifying individual members of the set"; since Bakalash does not 
disclose any such representation, the reference cannot disclose the further limitations of the 
representation and these claims as well are patentable in their own rights over the reference. 



35 



Claims 7-8 and 31-32 set forth further limitations concerning the step of "deriving the individual 
members specified in the representation of the set from values contained in entries belonging to 
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the plurality thereof. Because Bakalash does not disclose that step, the reference necessarily 
cannot disclose these further limitations, and these claims as well are patentable in their own 
rights over the reference, 

5 Conclusion 

Applicants have amended their claims to better distinguish them from Bakalash, have 
demonstrated that the claims as amended are fiiUy supported by the Specification as filed, and 
have further demonstrated that the claims as amended are not anticipated by Bakalash. 
Applicants have thereby satisfied the requirements of 37 C.F.R. 1.111(b) and respedfuUy 
10 request that Examiner enter the amendment and continue with her examination as provided by 
37 C.F.R. 1.111(a). A petition for a one-month extension of time and the requisite fee 
accompany this response. No fees are believed to be required by way of this response; if any 
should be, please charge them to deposit account number 501315. 

15 Respectfully submitted, 
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